git 提交记录回顾总结

说明

年前我需要写公司的年度工作总结，所以把项目里的提交日志拉出来查看，其中有几类提交是无效的也是没有意义的，整理起来十分蛋疼，所以记录下来。

示例

只有操作类型

• fix
• add

上面这两个可以知道是修复功能和添加功能，但是需要看代码才能知道修复的是什么，添加的是什么。

提交说明使用外文进行说明

• fix refund

英文不好的人可能看到英文得需要想几秒，甚至需要翻译。

无详细说明

• 严重BUG修复
• 退货退款时间记录

虽然知道是修复严重 BUG，但是 BUG 是什么功能，为什么是严重 BUG 并不知道。而第二种虽然没多大毛病，但改成 “补充遗漏退货退款完成时间” 会更好些。

多个功能混在一起提交

1. 修改xxx
2. 添加xxx
3. 去除xxx

不建议这样子提交，但是后面回顾代码的时候区分不出每个项对应的内容。不要怕提交条数多，如果需要审阅代码就知道分开提交的好处了。

无意义的说明

• 修复 xxx 文件

提交记录里会记录当次提交的所有文件，没有说明的意义。

使用 GitHub issues 的方式提交

• fix issues #894

这种提交是模仿 GitHub 上的提交方式，它会自动关联上指定的 issues，对直接在 GitHub 上审阅代码时很好用。但是对于完全独立的代码仓库来说，会不知道具体的问题是什么。可以保留这个方式写在说明第二行即可。gogs 也有类似的功能。但对于禅道，这种没有关联的来说，完全没有必要记录上去。

总结

1. 对提交进行分类
2. 统一提交格式
3. 过段时间回来查看提交记录还能看明白提交说明，那就代表说明表述上没有问题

feat: xxx 功能
详细说明：

fix: xxx 功能的 xxx 问题
详细说明：
关联issues：#123

del: xxx 功能[的 xxx 方法]
详细说明：

adjust: xxx 功能[的 xxx]
详细说明：

[] 为可选项